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Indicating Fax over IP Capability 
in the Session Initiation Protocol (SIP) 


Abstract 


This document defines and registers with IANA the new "fax" media 
feature tag for use with the Session Initiation Protocol (SIP). 
Currently, fax calls are indistinguishable from voice calls at call 
initiation. Consequently, fax calls can be routed to SIP user agents 
that are not fax capable. A "fax" media feature tag implemented in 
conjunction with caller preferences allows for more accurate fax call 
routing. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6913. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Fax communications in the Session Initiation Protocol (SIP) [RFC3261] 
are handled in a "voice first" manner. Indications that a user 
desires to use a fax transport protocol, such as ITU-T T.38 [T38], to 
send a fax are not known when the initial INVITE message is sent. 

The call is set up as a voice call first, and then, only after it is 
connected, does a switchover to the T.38 [T38] protocol occur. This 
is problematic in that fax calls can be routed inadvertently to SIP 
user agents (UAs) that are not fax capable. 


To ensure that fax calls are routed to fax-capable SIP UAs, an 
implementation of caller preferences defined in RFC 3841 [RFC3841] 
can be used. Feature preferences are a part of RFC 3841 [RFC3841] 
that would allow UAs to express their preference for receiving fax 
communications. Subsequently, SIP servers take these preferences 
into account to increase the likelihood that fax calls are routed to 
fax-capable SIP UAs. 
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This document defines the "fax" media feature tag for use in the SIP 
tree, as per Section 12.1 of RFC 3840 [RFC3840]. This feature tag 
will be applied per RFC 3841 [RFC3841] as a feature preference for 
fax-capable UAs. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. Motivation 


In the majority of circumstances, it is preferred that capabilities 
be handled in the Session Description Protocol (SDP) portion of the 
SIP [RFC3261] communication. However, fax is somewhat unique in that 
the ultimate intention of the call is not accurately signaled in the 
initial SDP exchange. Specifically, indications of T.38 [T38] or any 
other fax transport protocol in the call are not known when the call 
is initiated by an INVITE message. Fax calls are always considered 
voice calls until after they are connected. This results in the 
possibility of fax calls being received by SIP UAs that are not 
capable of handling fax transmissions. 


For example, Alice wants to send a fax to Bob. Bob has registered 
two SIP UAs. The first SIP UA is not fax capable, but the second one 
supports the T.38 [T38] fax protocol. Currently, SIP servers are 
unable to know at the time that the call starts that Alice prefers a 
fax-capable SIP UA to handle her call. Additionally, the SIP servers 
are also not aware of which of Bob's SIP UAs are fax capable. 


To resolve this issue of calls not arriving at a UA that supports 
fax, this document defines a new media feature tag specific to fax, 


per RFC 3840 [RFC3840]. Caller preferences, as defined in RFC 3841 
[RFC3841], can then be used for registering UAs that support fax and 
for routing fax calls to these UAs. Thus, Alice can express up front 


that she prefers a T.38 [T38] fax-capable SIP UA for this call. At 
the same time, Bob's SIP UAs have expressed their fax capabilities as 
well during registration. Now, when Alice places a fax call to Bob, 
the call is appropriately routed to Bob's fax-capable SIP UA. 
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4. 


Usage of the "sip.fax" Parameter 


The "sip.fax" media feature tag is a new string parameter, defined in 
this document, that allows a call to indicate a fax preference. A 
receiving UA includes the "sip.fax" media feature tag in the Contact 
header field of REGISTER messages to indicate that it is fax capable, 
and a SIP Registrar includes this tag in the Contact header field of 
its 200 OK response to confirm the registration of this preference, 
all as per RFC 3840 [RFC3840]. 


A calling UA SHOULD include the "sip.fax" media feature tag in the 
Accept-Contact header of an INVITE request in order to express its 
desire for a call to be routed to a fax-capable UA. Otherwise, 
without this tag, fax call determination is not possible until after 
the call is connected. If a calling UA includes the "sip.fax" tag 
and the SIP network elements that process the call (including the 
called UAs) implement the procedures of RFC 3840 and RFC 3841, the 
call will be preferentially routed to UAs that have advertised their 
support for this feature (by including it in the Contact header of 
their REGISTER requests, as documented above). 


It is possible for the calling UA to utilize additional procedures 
defined in RFC 3840 and RFC 3841 to express a requirement (instead of 
a preference) that its call be delivered to fax-capable UAs. 
However, the calling UA SHOULD NOT require the "sip.fax" media type. 
Doing so could result in call failure for a number of reasons, not 
only because there may not be any receiving UAs registered that have 
advertised their support for this feature, but also because one or 
more SIP network elements that process the call may not support the 
processing defined in RFC 3840 and RFC 3841. A calling UA that 
wishes to express this requirement should be prepared to relax it to 
a preference if it receives a failure response indicating that the 
requirement mechanism itself is not supported by the called UAs, 
their proxies, or other SIP network elements. 


When calls do connect through the use of "sip.fax" either as a 
preference or a requirement, UAs should follow standard fax 
negotiation procedures documented in ITU-T T.38 [T38] for T.38 fax 
calls and ITU-T G.711 [G711] and ITU-T V.152 [V152], Sections 6 and 
6.1, for fax passthrough calls. Subsequently, the "sip.fax" feature 
tag has two allowed values: "t38" and "passthrough". The "t38" value 
indicates that the impending call will utilize the ITU-T T.38 [T38] 
protocol for the fax transmission. The "passthrough" value indicates 
that the ITU-T G.711 [G711] codec will be used to transport the fax 
call. 
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5. Example 


Bob registers with the fax media feature tag. The message flow is 
shown in Figure 1: 


SIP Registrar Bob’s SIP UA 


Figure 1: Fax Media Feature Tag SIP Registration Example 


F1 REGISTER Bob -> Registrar 


REGISTER sip:example.com SIP/2.0 

Via: SIP/2.0/TCP bob-TP.example.com:5060;branch-z9hG4bK309475a2 
From: <sip:bob-tp@example.com>;tag=a6c85cf 

To: <sip:bob-tp@pexample.com> 

Call-ID: a84b4c76e66710 

Max-Forwards: 70 

CSeq: 116 REGISTER 

Contact: <sip:bob-tp@pc33.example.com;transport=tcp>;+sip.fax="t38" 
Expires: 3600 


The registrar responds with a 200 OK: 
F2 200 OK Registrar -> Bob 


SIP/2.0 200 OK 

From: <sip:bob-tp@example.com>;tag=a6c85cf 

To: <sip:bob-tp@example.com>; tag=1263390604 

Contact: <sip:bob-tp@example.com;transport=tcp>;+sip.fax="t38" 
Expires: 120 

Call-ID: a84b4c76e66710 

Via: SIP/2.0/TCP bob-TP.example.com:5060; branch=z9hG4bK309475a2 
CSeq: 116 REGISTER 

Expires: 3600 


Callers desiring to express a preference for fax will include the 


"sip.fax" media feature tag in the Accept-Contact header of their 
INVITE. 
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INVITE sip:bob@biloxi.example.com SIP/2.0 

Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 
Max-Forwards: 70 

From: Alice «sip:aliceQGatlanta.example.com»;tag-9fxced76sl 
To: Bob <sip:bob@biloxi.example.com> 

Accept-Contact: *;+sip.fax="t38" 

Call-ID: 3848276298220188511Gatlanta.example.com 

CSeq: 1 INVITE 

Contact: <sip:alice@client.atlanta.example.com;transport=tcp> 
Content-Type: application/sdp 

Content-Length: 151 


6. Security Considerations 


The security considerations related to the use of media feature tags 
from Section 11.1 of RFC 3840 [RFC3840] apply. 


7. IANA Considerations 


This specification adds a new media feature tag to the SIP Media 
Feature Tag Registration Tree per the procedures defined in RFC 2506 
[RFC2506] and RFC 3840 [RFC3840]. 


Media feature tag name:  sip.fax 
ASN.1 Identifier:  1.3.6.1.8.4.25 


Summary of the media feature indicated by this tag: This feature tag 
indicates whether a communications device supports the ITU-T T.38 
[T38] fax protocol ("t38") or the passthrough method of fax 
transmission using the ITU-T G.711 [G711] audio codec 
("passthrough"). 


Values appropriate for use with this feature tag: Token with an 
equality relationship. Values are: 


t38: The device supports the "image/t38" media type [RFC3326] and 
implements ITU-T T.38 [T38] for transporting the ITU-T T.30 
[T30] and ITU-T T.4 [T4] fax data over IP. 


passthrough: The device supports the "audio/pcmu" and "audio/ 
pcma" media types [RFC4856] for transporting ITU-T T.30 [T30] 
and ITU-T T.4 [T4] fax data using the ITU-T G.711 [G711] audio 
codec. Additional implementation recommendations are in ITU-T 
V.152 [V152], Sections 6 and 6.1. 
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9. 


9. 


Li 


The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 
This feature tag is most useful in a communications application 
for the early identification of a Fax over IP (FoIP) call. 


Examples of typical use: Ensuring a fax call is routed to a fax 
capable SIP UA. 


Related standards or documents:  RFC 6913 


Security Considerations: The security considerations related to the 
use of media feature tags from Section 11.1 of RFC 3840 [RFC3840] 


apply. 
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